In complex computing and data processing systems, authorization of access to components within a system is of a paramount importance. For example, a database system that maintains employee records for a company will manage authorization of access to the records with a list of users who are authorized to access the stored data. Individual users may have different authorization levels managed by the list, such that some users have access to only part of the data stored by the database system.
Role-Based Access Control (RBAC) is a very good model for managing users and their authorizations. In the RBAC model, authorizations are granted and revoked based on the specific roles with which a user is associated. The authorization to user assignment is expressed by policies that define the set of authorizations granted by membership to a role. FIG. 1 shows schematically the relationship between User, Role, Policy and Authorization. A user will be associated with one or more roles (based upon the user's assigned responsibilities), and each role has a policy defined that gives one or more authorizations in relation to one or more systems which the user can access.
Current systems that provide functionality to support RBAC on multiple platforms (such as IBM Tivoli Identity Manager—ITIM) support two methods of administration: RBAC and manual assignment of individual authorizations. The RBAC model is advantageous because it ties authorizations to the roles the user performs in a business context, using a set of policies. The manual model is advantageous because it is very flexible, and allows fine grained control on a per-user basis. In real world implementations, the data processing system aims to implement a fully RBAC model but often a combination of RBAC and the manual model is required to allow the full set of authorizations to be assigned to users. FIG. 2 shows schematically how authorizations are generated for a user, where RBAC authorizations are granted and revoked based on role membership, and individual authorizations are managed by a human administrator.
When authorizations are applied to a target system (i.e. the end system is informed that user x has an authorization with respect to that system) there is no way to tell how the original assignment to the user was made (it can be assigned either by role, individually or both). This occurs because most systems are not prepared for a management layer and have fixed data models for the authorization data (i.e. they have a single field for groups on the user account). The management systems of today adopt the data model from the targets systems and therefore use a single field for authorization data (typically groups).
Support for individual authorizations can be achieved by creating a role for each authorization but this approach has a major drawback in the number of roles in the system. If the RBAC system manages large systems then the number of roles can easily exceed 20,000, and this makes management difficult. Individual authorizations are managed by a human administrator.